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FOREWORD 


This Indian Standard was adopted by the Bureau of Indian Standards, after the draft finalized by the Smart 
Infrastructure Sectional Committee, had been approved by the Electronics and Information Technology Division 
Council. 


In the formulation of this standard, considerable assistance has been derived from the following publications: 

a) ISO/IEC 30141 : 2018 Internet of Things (IoT) — Reference Architecture 

b) ITU-T Y.3056 Framework for bootstrapping of devices and applications for open access to trusted 

services in distributed ecosystems 

c) TEC 30001 : 2020 oneM2M Functional Architecture 

d) TEC-TR-SN-M2M-009 — Release 01 Recommendations for ТоТ / M2M Security (Technical report) 
The IoT Concept Model Diagram and Definitions used in this document are adapted from the ISO/IEC 30141, 
the Functional Architecture has been adapted from ITU-T Y.3056, and The Common Service Layer architecture 


has been adapted from the TEC 30001 : 2020. The Classification of Use Cases (Cl 8.2.2) is derived from 
TEC-TR-SN-M2M-009. 


The IoT Reference Architecture described in this Standard aims to fulfil the broad requirements identified 
in IS 18004-6 Functional Requirements of IoT Systems (under development) and TEC 30002 : 2020 
oneM2M-Requirements. 


The Department of Telecommunications, Ministry of Communications, Government of India vide Gazette 
Notification No. G.S.R. 1131(E) dated 5th September, 2017 has amended the Indian Telegraph Rules, 1951 
(Amendment 2017) to introduce Mandatory Testing & Certification of Telecom Equipment (MTCTE). As per 
MTCTE, every telecom equipment must undergo mandatory testing and certification before its sell or import. 


The requirements for the security management (8.2) has been set to fulfil the requirements for the MTCTE. 


The Composition of the panel, LITD 28/P9 and the sectional committee, LITD 28 responsible for the formulation 
of this standard is given at Annex C. 
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0 INTRODUCTION 


0.1 Background 


The Internet of Things (IoT) or Machine to Machine 
(M2M) ecosystem generally comprises of devices 
and/or sensors which generate information in the 
form of data which flows through various electronic 
communication means to a set of Digital Infrastructure 
for storing, forwarding, analysis, and subsequent 
actions by humans or machines including actuators. 


0.2 Motivation & Objectives 


IoT is considered to be a significant element ofthe digital 
infrastructure and is an integral part of the ‘Unified 
digital infrastructure ICT Reference Architecture 
(ICTRA) defined in IS 18000. Therefore, it is necessary 
to provide a special focus on the standardization of the 
IoT Ecosystem. 


This Standard recommends a blueprint for realizing the 
digital infrastructure required for scalable, secure and 
globally interoperable IoT solutions. The IoT Reference 
Architecture described in this Standard includes a 
concept model, reference models, architectures and 
deployment views, along with references to global 
standards and specifications, such as to facilitate an 
orderly proliferation of the IoT Ecosystem. 


A significant other motivation is to ensure that the 
IoT sub-systems seamless integrate with the sub- 


iii 
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systems involved with performing towards the ICT RA 
specifications. The IoT RA focuses on the three key 
principles enshrined in the ICT RA, namely: 


a) Interoperability — Refers to the ability of 
diverse systems and components to work 
together, even as parts from diverse set of 
suppliers are substituted and integrated; 
Composability — Refers to the ability to 
combine discrete components into a complete 
system to achieve a set of goals and objectives; 
and 


b 


— 


c) Harmonization Refers to achieving 
compatibility between technologies апа 
systems, even when they at first appear 


incompatible. 


The Standard is useful for anyone involved in the 
design, development, deployment, and implementation 
or certification of an ТоТ device, network or application 
ecosystem. Further, the IoT Reference Architecture 
assists in obtaining the objectives of IS 18000, 
which are to provide a unified digital infrastructure 
architecture that can serve as a template for both the 
city administrators and those who are the consumers 
of such IoT and ICT based solutions, as well as the IoT 
and ICT solution providers who develop and deploy 
such solutions. 


This page has been intentionally left blank 
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Indian Standards 
IOT SYSTEM 


PART 1 REFERENCE ARCHITECTURE 


1SCOPE 


This Indian Standard describes the Internet of Things 
(IoT) Reference Architecture, that comprises IoT 
Concept Model, IoT Reference Models (Domain based 
IoT reference model, Entity based IoT reference model) 
and IoT Deployment Views. 


IoT Concept Model and Reference models elaborate 
the interactions between various entities, both digital 
and non-digital. 


2 REFERENCES 


The standards given below contain provisions which, 
through reference in this text, constitute provisions of 
this standard. At the time of publication, the editions 
indicated were valid. All standards are subject to 
revision, and parties to agreements based on this 
standard are encouraged to investigate the possibility 
of applying the most recent editions of these standards.* 


IS 18000: 2020 Unified Digital Infrastructure ICT 


Reference Architecture 

IS 18002 Unified Digital Infrastructure 

(Part 1) : 2021 Data Layer Part 1 Reference 
Architecture 
ISO/IEC 30141 Internet of Things (loT) - 
Reference Architecture 

TEC 30001 : oneM2M Functional Architecture 
2020 

TEC 30003 : oneM2M- Security Solutions 
2020 

TEC 30004 : oneM2M-Service Layer Core 
2020 Protocol 

TEC 30009 : oneM2M-HTTP Protocol Binding 
2020 

TEC 30010: oneM2M-MQTT protocol binding 
2020 

TEC 30015 : oneM2M-Testing Framework 
2020 

TEC 30020 : oneM2M-WebSocket Protocol 
2020 Binding 

ITU-T Y.3056 Framework for bootstrapping 
(2021) of devices and applications for 


open access to trusted services in 
distributed ecosystems 


3 TERMINOLOGY, 
ABBREVIATIONS 


SYMBOLS AND 
3.1 Terminology 


For the purpose of this standard, the definitions given in 
IS 18000 : 2020 and ISO/IEC 30141 shall apply. 


3.2 Abbreviations 
API Application Programmable Interface 
CSF Common Service Function 
FA Functional Architecture 
IoT Internet of Things 
JSON JavaScript Object Notation 
M2M Machine-to-Machine 
OTP One-time-password 
RA Reference Architecture 
RM Reference Model 
SEM CSF Semantics (SEM) Common Service 
Function 
SP Service Provider 
TSP Telecommunications Service Provider 
XML Extensible Markup Language 
4 OVERVIEW 


Internet of Things (IoT) refers to a vast and growing 
collection of devices and applications that are 
connecting every part of our lives today. The IoT use 
cases are spread into smart city, smart grid, smart home 
and building, digital agriculture, smart manufacturing, 
intelligent transport system, e-Health etc. IoT is a 
general reference to many enabling technologies 
including sensing, networking, communications, data 
management, control, analytics etc. The IoT Reference 
Architecture described in this standard comprises a set 
of models, architectures and views, the overall structure 
of which is depicted in Fig. 1. 


4.1 IoT Concept Model 


The IoT concept model is an abstract, implementation 
independent representation of the actors, entities, 
interactions and enforcements required for 
supporting the requirements and use cases in the IoT 
ecosystem. 
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4.2 IoT Reference Model 


The IoT reference model describes the important 
domains and the entities within the domains. It also 
presents the three types of interactions between the 
domains that are important to the IoT ecosystem: 
human-machine interactions, machine-machine 
interactions and inter-domain interactions. Two 
approaches have been adopted while arriving at the 
IoT Reference Model namely Domain based Reference 
Model and Entity based Reference Model. 


4.3 IoT Reference Architecture 


The IoT Reference Architecture is described through 
the ТоТ Functional Architecture and the IoT Service 
Layer Architecture. 


4.4 IoT Deployment Views 


For the implementation of the IoT System, the IoT 
Reference Architecture needs to be realised using clear 
definitions of the roles, the subsystems which include 
the device and data management subsystems and also 
the security management system. A set of deployment 
views are provided to assist the implementation of 
the ТоТ system using the IoT Reference Architecture. 
The following deployment views are provided in the 
document: 


a) IoT Role Based View 


b) IoT System Deployment View 
с) ТоТ Security Management View 


5 IOT CONCEPT MODEL 


For the IoT Conceptual Model, reference is drawn 
towards ISO/IEC 30141 : 2018, 8.3 providing the high 
level IoT Concept Model which describes the common 
structure and definitions for describing the concepts, 
relationships, and behaviour within an 1оТ system. 
The primary objective of the IoT concept Model is 
to provide a common structure and definitions for 
describing the concepts of, and relationships among, 
the entities within IoT systems. 


The IoT Concept Model benefits the emerging 
requirements from a wide array of Use Cases belonging 
to an ever growing industrial, home and governmental 
sectors as well as Smart City use cases covering 
Safety and Surveillance, Health, Education, Energy, 
Utilities, Transportation, Governance, Sustainability 
and Buildings. It aims to be generic, abstract and 
simple in order to address the various IoT use cases in a 
standardised manner across all vertical domains. 


The IoT Concept Model shown in Fig. 2 presents the 
relationships between the entities, including Digital 
Entities and their Physical Entities. It also illustrates 
how things and services collaborate via the network. 
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Fic. 2 IoT Concept Mopzr [Source: ISO/IEC 30141] 


An Entity is anything (both physical and non-physical) 
that has a distinct and independent existence. Every 
entity has a unique identity. 


A Digital Entity is a computational or data element of 
an IoT system. These elements include applications, 
services, virtual entities, data stores, IoT devices and 
IoT gateways. A Digital Entity is a specialization 
of Entity. A Digital Entity can contain other Digital 
Entities. 


A Physical Entity is a discrete, identifiable and 
observable part of the physical environment. 
Physical Entities can be almost any physical object 
or environment; from humans or animals to cars; 
from store or logistics chain items to computers; from 


electronic appliances to closed or open environments. A 
Physical Entity is a specialization of entity. A Physical 
Entity can contain other physical entities. 


An IoT-User is a user of an IoT system, which can 
be human or non-human. An IoT-User is part of an 
IoT system. An IoT-User is a specialization of entity 
representing a human user or digital user. 


A Network is the infrastructure that connects a set 
of Digital Entities, enabling communication of data 
between them. A network is a specialization of entity. 


Most entities in IoT, especially Physical Entities 
("things"), have an Identity. An Identifier is a set of 
attributes of the entity that can be used to uniquely 
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identify the entity in a context. An entity can have more 
than one identifier, but it requires at least one unique 
identifier within any Identity Context through which it 
can be accessed. For example, the identity information 
from a tag can be used as an identifier to identify the 
Physical Entity to which it is attached. 


Entities which interact via networks do so by exposing 
one or more endpoints on a network. A network 
connects endpoints. A Service exposes one or more 
endpoints by which it can be invoked. An endpoint has 
one or more network interfaces. Services, which are 
located remotely, can be reached by endpoints through 
network interfaces across a communication network. 
Endpoints exist on one or more networks. 


A Service is a set of distinct capabilities provided 
through a defined interface. A service can be composed 
of other services. A service is typically implemented as 
software. A service defines network interfaces and is 
exposed by an endpoint. A service interacts with other 
entities via one or more networks. A service may or 
may not 


a) interact with IoT gateways or IoT devices 
b) interact with other services 
C) use data stores 


Data associated with services, IoT devices and with IoT 
gateways can be held in a Data Store used by one or 
more entities. 


An Application is a software entity or system that 
offers a collection of functions and solutions designed 
to help IoT users perform particular tasks or to handle 
particular types of IT problems. An application can use 
one or more services. Ап application can be used by 
a human user (via a human-machine interface (HMI)) 
or by a digital user (via an API). The Services and 
Applications are illustrated in the Reference Models 
described in 6.1 (see Fig. 3). 


An interface is defined as a named set of operations that 
characterize the behaviour of an entity and is specifically 
a set of operations and associated parameters which can 
be used by one Digital Entity to request actions from 
another Digital Entity. 


The Concept Model also addresses the OT Asset 
Management as given in clause 8.11.2 of IS 18000, 
which requires that the management of all IT or non-IT 
field device should be protected and managed. Every 
such device should be easily identifiable through a well- 
defined asset tagging mechanism, maintained in an 
asset registry using the asset tag as the key, identifying 
asset ownership and custodian. The registry must 
maintain the entire lifecycle of the asset, right from its 
procurement, installation, maintenance to disposal of a 
device. 


The Concept Model also addresses the Field Security 
Management requirements given in clause 8.11.6 of 
IS 18000, which requires that the IoT devices 
are genuine, the firmware and/or software are not 
compromised and that they are authenticated, authorized 
and managed using security keys so as to be protected 
against cyber-attacks throughout the lifecycle. 


6 IOT REFERENCE MODELS 


6.1 Domain Based Reference Model 


The IoT Domain based Reference Model (RM) 
depicted in Fig. 3 is shown as a set of entities within 
well-defined domains which interact with each other 
whilst being governed by a set of Policy, Regulatory, 
Governmental Guidelines, and Standards. 


In order to provide a sustainable, interoperable, 
standardised апа scalable framework for Ше 
proliferation of the loT Use Cases, these concept model 
envisages the need for loT Reference Models which can 
be used to develop implementation models for various 
use cases across sectors. 


The Entities in the Domain based IoT RM represent both 
Physical and Digital entities as they form a relationship 
with each other including the devices, networks, 
platforms and applications as illustrated in Fig.3. Though 
Fig. 3 depicts the interactions between domains, the 
actors and entities have however been shown here 
within the domains for exemplification. 


The following domains are important from the 
perspective of a standardised ТоТ Ecosystem: 


a) Device / Network Domain 

b) Consumer Domain 

c) Provider Domain 

d) Service / Application Domain 


e) Standards / Policy / Regulatory / Governance 
Domain 


f) Trust Establishment, Registration, Certification 
Domain 


It acknowledges the existence of multiple entities, 
including but not limited to Device Manufacturer, App 
Developer, Device or App Buyer, Device or App User, 
Various Service Providers, System Integrators, Trust 
Providers, Regulators, Registration and Certification 
Authorities and Application Verticals etc. 


In Fig. 3, the horizontal domains have been depicted 
using rectangular shapes with rounded edges having 
dotted boundaries. The two vertical domains have 
been represented using sharp edged rectangles with 
dotted boundaries. The horizontal domains are more or 
less specific to the actors or entities depicted therein 
and have interactions with more than one domain. 
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Fic. 3 DOMAIN BASED IOT REFERENCE MODEL 


The vertical domains are the ones which encompass 
the entire IoT ecosystem and are mainly driven by 
standards, policy, regulatory frameworks, governance 
etc. There are two pillars shown at the two sides of the 
diagram which germinate from the model contained 
within. They are: 


a) IoT Reference Architecture 
b) IoT Deployment Views 


The following three types of interactions are used in 
Fig. 3: 


a) Human to Machine Interaction (HMI) — 
These are mainly the interactions between 
human entities with machines or subsystems. 
The arrows depicting these interactions cross 
the domain boundary which signifies that the 
interactions are between the actors and/or 
entities within a specific domain to other actors 
and/or entities. 


Machine to Machine Interaction (M2M) — 
These are the interactions between machines/ 
subsystems mainly between the actors or 
entities of the Device/Network Domain and 
the Service/Application Domain. The arrows 
depicting these interactions also cross the 
domain boundary signifying such interactions. 


b) 


Domain to Domain Interaction (D2D) — 
These are the interaction between the domains 
and does not indicate any specific actor or entity 


contained within the individual domains. The 
arrows depicting these interactions, therefore, 
do not cross the domain boundary and that 
signifies that the interactions are between the 
entirety of the domains. 


6.2 Entity based IoT reference model 


The entity based IoT Reference Model is shown in 
Fig. 4. While the Domain based IoT Reference Model 
described the domains from the perspective of HMI, 
M2M and D2D interactions, it is also necessary to 
consider the physical and digital entities and the 
interactions between them. The concept of layers is 
introduced in this description in the following way: 


а) Users or Application Layer — This layer 
contains the State/Corporate Entity, Consumer 
Entity and Governance Entity 

b) Services Layer — This layer contains the IoT/ 

M2M Data Management Entity and IoT/M2M 


Service Entity 


Network Layer — This layer contains the 
various Network Entities of an IoT ecosystem 
namely Public Network, M2M Area Network 
(also known as Personal Area Network) and 
Captive Network. 


c) 


d) Physical Layer — This layer contains the 
physical Entities that are Sensors/Actuators 


and IoT/M2M Devices/Gateways 
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Fic. 4 ENTITY BASED ТОТ REFERENCE MODEL 


The layers, along with the related entities, cut across 
and operate at three planes, namely: 
a) IoT/M2M Functional Plane, 
b) IoT/M2M Standards Certification 
Compliance Plane 


c) IoT/M2M Data and Security Management 
Plane 


and 


7 IOT REFERENCE ARCHITECTURE 


The IoT Reference Architecture (IoT RA) is derived 
from the two reference models described in 6 which 
described the Domains, Entities and their interactions. 


The IoT System implemented in the city shall adhere 
to the Unified Digital infrastructure (UDI) properties 
defined in IS 18000 and the data principles defined in 
Table 1 of IS 18002. 


The various layers and planes described in 6 are further 
detailed in a layered architecture. The IoT Reference 
Architecture 1s created from a deployment perspective, 
it provides for the implementation of the individual 
components and the interaction between the different 
layers. Each layer talks to the other layer as shown in 
Fig. 5 below without ignoring any one of them. Each of 
the layers is technology agnostic. 


7.1 IoT Architecture Layers and Planes 


Fig. 5 shows an abstract view of the IoT Reference 
Architecture that comprises four layers. It also 
demonstrates the interaction between the different 
layers both at the horizontal and vertical level. 
The architecture is technology agnostics such 
that it gives guidance to architect an IoT System. 
Each layer of the IoT Reference Architecture 
is explained as below. 


7.1.1 Physical Layer 


Consists of "things" that have independent existence 
and consists of sensors, actuators, gateway devices 
that capture the real time and offline data from the 
environment. 


7.1.2 Network Layer 


This layer encapsulates the different communication 
technologies and protocols that constitute an IoT 
Network as suggested by the domain-based reference 
model mentioned in 6.1. 


7.1.3 Common Service Layer 


As the name suggests, this layer is the common service 
utility layer for the IoT platform. All the necessary 
functions of any IoT Ecosystem is contained here that 


can be provided as a service. These are called Common 
Service Functions (CSFs). Example of such Common 
Service Functions are registration and authorization; 
secured data exchange; location services; notification 
and event detection services; data storage and data 
exchanges; and Semantics (This module enable 
applications to manage semantic information and 
provide functionalities based on this information). 
Refer TEC 30001 : 2020, TEC 30004 : 2020, and 
TEC 30003 : 2020 for the Common Service Layer and 
its constituent Common Service Functions. 


This layer provides the APIs to access the physical 
entities and exchange data between the physical entities. 


7.1.4 Application Layer 


This Layer encapsulates the components which are 
providing the interfaces or visualisation which enables 
the Human to Machine Interactions. The Digital 
Entities which add meaning to the things are contained 
in this layer that may also provide user interfaces that 
act as a dashboard for the end users and interacts with 
the Common Service Layer. 


7.1.5 Functional Plane 


The said four layers perform the functions on any or all 
of the three planes depicted in Fig. 5. The Functional 
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Plane provides the management aspect of the entire IoT 
ecosystem be it the Digital Infrastructure Management, 
Agreements, Contracts, Workflow Management etc. 
The ‘Reliability’ of an IoT System, which is the ability 
to perform the intended function in the prescribed 
conditions for a specific period of time that can be 
measured in various metric form such as Quality of 
Service, Availability of Service etc. is one of the key 
deliverables of this plane and that cut across all the 
components of all the four layers. 


7.1.6 Data and Security Management Plane 


Data and Security Management Plane covers the 
aspects of Security and its association with Data that 
is generated by the IoT Ecosystem. Security in the IoT 
Ecosystem has another dimension in the perspective of 
Safety. Safety in IoT parlance 1s defined as a condition 
in which the IoT System operates without causing any 
injury or damage to human health either directly or 
indirectly or posing any risk to the environment Safety 
is a major concern for the IoT systems not only with 
respect to the human beings but also to other living 
beings and environment as it interacts and applies 
control mechanism for the physical world. Safety can 
not be compromised at any entity starting from the 
physical entity to the application entity. A wrong data 
captured by a physical entity can lead to wrong control 


Sa 


Application Layer 


Common Service Layer 
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mechanism at the application levels and may lead to 
safety issues not only to human lives but also to the 
environment where the IoT system is operating. 


Similar to the Cybersecurity ecosystem, the Security 
of an IoT System can be defined as the condition in 
which there is no compromise of data while flowing in 
or out of the IoT System. This includes the information 
systems involved, the physical systems, and the 
controlling systems. 


Information Security is the major threat in the context 
ofthe IoT System. IoT Systems pose a big challenge in 
terms of Information Security as they are distributed 
and connected and hence create a big challenge as 
there may be a huge number of IoT systems installed 
in the network. Any compromise in one of the IoT 
systems makes the complete network vulnerable. 
The main objective to have Safety and Security 
across the IoT Reference Architecture is to ensure the 
Confidentiality, Integrity and Availability of the IoT 
Systems. 


7.1.7 Standards, Certification and Compliance Plane 


Standards, Certification and Compliance Plane binds 
all the components of the IoT ecosystem with the 
standards, its certification methods and compliance when 
itis mandated orrecommended. The policies, regulations 
and legal aspects are all covered under this plane and 
thus establishes a framework that binds the entire 
ecosystem. 
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7.2 IoT Functional Architecture 


The IoT Functional Architecture (FA) is shown in 
Fig. 6. The IoT FA is derived from TEC 30001 : 
2020, and in alignment with TEC 30004 : 2020 and 
TEC 30003 : 2020. The IoT FA defines five nodes 
(see note), five functions and four reference points. 
The reference points are called RPa, RPc, RPn and 
are further suffixed with numerals to show the distinct 
interfaces between nodes. 


a) RPa 15 the reference point between the 
Application Functions and Common Service 
Functions. 


RPd is the reference point between the cyber- 
physical device and common service function. 


RPc is the reference point between two 
common service functions within a realm 


RPo is the reference point between two 
common service functions outside each other's 
realm 


C2 1s the reference point between two common service 
functions and N1 is the reference point between device 
functions and network functions. All four functions 
will interact with each other based on these reference 
points. There 1s another block parallel to the common 
service function that may be called a supporting/utility 
function block that only interacts with the CSF and 
this supporting /utility function is out of the scope of 
the ТоТ RA. 


Other realm 
Application 
Function 


nction 


Other realm 
CS Function 


A " 


Implementation specific, outside the scope of loT RA 


IONAL ARCHITECTURE 


7.3 Entity based components and functional blocks 


Table 1 lists out the different functions of Common 
Service Layer with a brief explanation. 


7.4 Sematic Interoperability 


In the IoT ecosystems, the various devices and 
applications operate without adequate compatibility with 
products from different manufacturers. For example, 
Smart Street Light application provided by one vendor 
does not work seamlessly with the lights provided by 
another vendor. This leads to a vendor locked-in siloed 
environment. standards resolve this issue by enabling 
horizontal and vertical communication, operation, and 
programming across devices and platforms, regardless 
of their model or manufacturer. Though standardised 
common service layer solves this problem to a great 
extent in order to utilize the full potential of the 
interoperable IoT ecosystem, standardised semantic 
annotations, mashups and semantic reasoning is 
necessary. The commonly agreed information models 
and ontologies for the data produced by the IoT devices, 
that are processed by the interfaces or are included in 
the exchanged data can provide the required meaning 
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of the data. However, as there are several ontologies 
for describing each distinct Thing, we need semantic 
interoperability mechanisms to perform common data 
mapping across the various utilized formats (e.g. XML 
or JSON) and ontology alignment. 


7.5 Functional description of the Semantics CSF 


The architectural model assumed in this standard is 
based on the generic architecture for the Common 
Service Layer in Fig. 5. The core functionality 
supporting semantics resides at various common 
service entities, providing services to the application 
entities interacting with other common service 
entities. 


The Semantics (SEM) Common Service Function 
(CSF) enables semantic information management 
and provides the related functionality based on 
this semantic information. The functionality 
of this CSF is based on semantic descriptions. 
This functionality is also enabled by other, more 
generic, resources and procedures described in 
TEC 30001 : 2020 and further referenced in this 
specification. The main features of the SEM CSF 


Table 1 Functions of Common Service Layer 


SI Functions 


Description 


1 Registration (REG) 


2 Discovery (DIS) 


3 Security (SEC) 
4 Group Management (GM) 


5 Data Management and Repository (DMR) 

6 Subscription and Notification (S&N) 

7 Device Management (DM) 

8 Application and Service Management 
(ASM) 

9 Location (LOC) 

10 Network Service Exposure (NSE) 

11 Communication Management and 
Delivery Handling (CMDH) 


12 Service Charging & Accounting (SCA) 


13 Transaction Management (TM) 


This function will enable the registration of the Applications (and each instance of the 
application) with the CSF 


This function allows the application to discover the resources (devices as well as 
applications) within the CSF 


This module ensures security of the data as well as communication 


CSF allows the application to create groups for different IoT devices to initiate a 
common action for the group 


This block manages the storage of data within the CSF and facilitates data exchange 
within the applications 


The module is responsible for notifying applications about data arrival or events. The 
individual application needs to subscribe for such notification. 


This module is responsible for the management of devices based on different 
technologies such as TR069, L:WM2M, OMA-DM 


The management of applications and service subscriptions is done by this module 


The location services and data management are taken care by the Location entity in 
the CSF 


This module facilitates the IoT System to choose the optimal network for application 
& device triggering. 


The module is responsible for the frequency and the channels of the communication 
taking place in the IoT System. 

This module is responsible for providing charging data for billing and accounting 
purpose. 


This module takes care of the scheduling of a transaction, locking and unlocking of 
resources targeted by a transaction. 
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are listed in clause 10.2.14 of TEC 30001 : 2020 
and further detailed in 6 and 7 of this standard. The 
SEM CSF includes specialized functional blocks such 
as SPARQL engine, repositories for ontologies and 
semantic descriptions, which may be implemented via 
permanent or temporary Semantic Graph Stores, etc. 


8 IOT DEPLOYMENT VIEWS 


8.1 General 


In order to implement the IoT System following the 
IoT Reference Architecture, it is important to describe 
and understand the roles which are necessary to be 
played by the corresponding stakeholders. Similarly, 
the functional blocks described in 7 shall have to be 
expanded in a way that can touch upon all the necessary 
components of practical deployment. Also, as the 
device, data security and privacy aspects are paramount 
in the IoT ecosystem, it is prudent to have a very precise 
and crisp specification for security implementation in a 
real IoT world. 


This objective is being met by the following three 
views that have been presented in this section: 


a) IoT Role Based View 
b) IoT Systems Deployment View 
c) IoT Security Management View 


8.1.1 /oT Role Based View 


The three layered IoT Reference Architecture described 
in 7 gets manifest in various deployment views. A 
generic form of the deployment view is illustrated in 
Fig. 7 which is developed keeping in mind the key 
stakeholders from the perspective of the roles played 
by them towards the service delivery and consumption 
standpoint of the IoT ecosystem as presented in Fig. 7. 
These roles are purely functional and may coincide or 
clubbed with any other role. 


The roles depicted in Fig. 7 are described as follows: 
a) The User (individual or company) fulfils all of 
the following criteria: 
1) Lawfully subscribes to an IoT/M2M 
solution. 
b) The Application Service Provider fulfils all of 
the following criteria: 
1) Registers the ^ Application, gets 
it certified as per the provisions 
of the law, and provides it as 
an IoT/M2M Application Service. 
2) Operates IoT/M2M Applications. 
c) The IoT/M2M Service Provider fulfils all of 
the following criteria: 
1) Obtains the required registrations and 
certifications for the provisioning of end 


to end IoT Services including devices, 
connectivity and applications, undertakes 
the custodian КҮС, provisions the 
IoT/M2M Services for retail, enterprise 
and government beneficiaries. 


2) Operates the IoT/M2M Services. 


d) The Network Service Provider fulfils all of the 
following criteria: 


1) Provides Connectivity and related services 
for IoT/M2M Service Providers. 


2) Operates an Underlying Network. Such 
an Underlying Network could, for 
example be a licensed telecom network 
or an unlicensed Machine to machine 
connectivity network 


e) The Device Manufacturers fulfil all the 
following criteria: 


1) Manufacturers/Provides the devices 
(sensors/actuators/gateways) in the field 


2) Conforms to the specifications of the 
standards as applicable in the IoT/M2M 
ecosystem 


All the above roles are having mapping to various 
layers as defined in the IoT RA and are governed by 
the Governance, Regulations and Standards entities as 
defined in the IoT Reference Model. 


8.1.2 IoT System Deployment View 


From the deployment standpoint, the layered 
architectures facilitate the understanding of roles, 
functions, positions, and the abstraction of different 
hardware, software and networking entities. Fig. 8 
gives an elaborate view of the entities and functions 
involved in the deployment of the IoT ecosystem. 


The deployment view is the layered representation 
of the way the IoT devices, associated applications, 
service functions and other related entities interact 
with each other. The associated functions and 
other related entities like Information Technology 
Service Management (ITSM), Disaster Recovery 
and Business Continuity Management (BCM), Data 
Centre Network Management System (DCNMS), 
Configuration Management, Microservice 
Management and Orchestration, Autoscaling and CI/ 
CD (Continuous Integration/Continuous Deployment) 
etc. though extremely important, are implementation 
specific entities and hence are out of scope of this 
standard. 


This deployment view is derived from the IoT Service 
Layer Architecture and IoT Functional Architecture. 
TEC 30001 : 2020, TEC 30004 : 2020, TEC 30009 : 
2020, TEC 30010 : 2020, TEC 30020 : 2020 were also 
referred to for validating the deployment scenarios with 
reference to the specifications contained therein. 
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8.1.2.1 Node based Deployment Architecture view 


An IoT application deployment as per the IoT Reference 
Architecture would have the following nodes: 


a) Field domain sensor nodes: These are the field 
domain nodes connecting the sensors and/or 
actuators directly using a wired interface. They 
communicate to the Common Service Layer 
through one or more Gateway nodes using any 
form of network connectivity. 


b 


ma 


Level one Gateways: These are the nodes that 
connect to one or more types of sensors and/ 
or actuators and may have multiple instances 
of the applications with the business logic of 
the respective vertical segments being catered 
to by them. These nodes can connect to the 
common service layer of the nodes placed 
hierarchically above them either in the field 
domain or in the infrastructure domain i.e. 
the Service Providers’ domain having core 
infrastructure. 


С 


— 


Level two Gateways: These are the Gateway 
nodes that must have the field domain form of 
common service layer and would essentially 
connect to the field domain sensor nodes 
either directly or through level one gateways 
or through another level two gateway. They 


Application1 


Application 2 


Network Service Provider 1 


Common Service Platform 
(IoT Service Provider1) 


Wired 
connectivity 


w 


would also connect to the common service 
layer in the infrastructure domain. More often 
than not they are termed as the aggregation 
gateways. 


d) Service Providers’ Domain Infrastructure: 
The core infrastructure that would provide the 
majority of the services as articulated as part 
of the common service layer. For the sake of 
differentiation from the field domain common 
service layer, this infrastructure is termed 
as Common Service Platform of the Service 
Provider. 


— 


A simplistic illustration of ТоТ application deployment 
using the above nodes following the IoT RA is given 
in Fig. 9 which is in harmony with TEC 30001 : 2020, 
TEC 30004 : 2020, TEC 30009 : 2020, TEC 30010 : 
2020, TEC 30020 : 2020 and also with TEC 30003 : 
2020. 


8.2 IoT Security Management View 


The Security management shall adhere to the following 
requirements (refer TEC 30003 : 2020 for more details): 


a) Unique identification and registration of IoT 
Devices and Applications framework based on 
a trust framework permitting sectoral, national 
and international registrars 


Application 3 Application 4 
Network Service Provider 2 


Common Service Platform 
(IoT Service Provider2) 


LORaWAN 
= 


L1-G : Level one Gateway having applications with the business logic of the respective vertical segments 


L2-G : Level two Gateway essentially having the field domain form of common service layer 
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b) Registration of Service Providers to the 
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respective trust authorities, registrars (Telecom 
Service Providers, Machine to Machine Service 
Providers, Application Service Providers) 


Classification of Use Cases and differential trust 
requirements based on these classifications 


Identification and registration of IoT/ M2M 
Applications and the M2M Devices, tamper 
resistant roots of trust for mission critical and 
sensitive use cases 


Mandatory testing and certification of all 
connected devices and applications by the 
Original Equipment Manufacturer in India or 
the person importing telegraph (device) for 
sale in India as per Gazette Notification No. 
G.S.R. 1131(E) dated 5th September, 2017 of 
Department of Telecommunications, Ministry 
of Communications, Government of India. 


The connectivity elements shall be compliant 
to the relevant Generic Requirements(GR), 
Interface Requirements(IR) and Essential 
Requirements (ER) published by TEC. 


Mutual Authentication and Authorization of 
security nodes belonging to service providers, 
application providers and registrars using 
online and real time systems 


Frequent and regular mutual authentication 
between devices and the servers receiving and 
hosting the data from the device 


Remote management and configuration shall 
be compliant to national and international 
standards like ETSI TS 101 181 V8.9.0 or 
OMA DM (wireless) or BBF TR-69 (wireline) 


Location information requirement for mission 
critical use cases 


Identities and information elements that 
are private and sensitive to users, networks 
or service providers shall be transported 
encrypted and transformed such that the real 
identities are only known to the party that 
owns the private data and not to agencies that 
are transporting or processing the information. 


Principles of ‘secure by design’ and ‘end 
to end encryption’ shall be applicable, 
security algorithms and key management for 
encryption and signing shall be based on use 
case classification and minimum requirements 
as specified by the relevant regulations. 


Device identity, may be linked to the globally 
unique, tamper resistant identity provided by a 
TSP/M2MSP, providedthat the tamperresistant 
secure element of the device is provisioned with 
the custodian (for example Aadhaar), machine 
(for example vehicle chassis number) and 
communication identity (for example IccID/ 
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EID) by the sectoral registrar (for example 
vahan or AIS140 backend server) using bi- 
directional authentication based on keys and 
certificates stored on the secure element of the 
device (secure authentication channel) 


Custodian verification and Know Your 
Customer (KYC) norms for devices using 
embedded and tamper resistant roots of 
trust shall be simplified if the inherent trust 
capabilities of the device and service provider 
are used. The M2M SP/ TSP shall be allowed 
to access the manufacturer's data lawfully 
published on the servers of sector registrar 
servers by the manufacturer, by using their 
authenticated user access provided by the trust 
registrar. 


For the pluggable SIM that can be changed 
in the field by the customer, the custodian- 
machine KYC shall follow the digital KYC 
processes as specified by the department of 
telecommunications from time to time. 


The КҮС may be completed by the TSP/ M2M 
SP digitally and remotely, if using its private 
key to retrieve the secure triplet from the 
secure element, and having that information 
verified by the custodian using an one-time- 
password (OTP) to the mobile number of the 
custodian registered with the sector registrar as 
an owner of the machine. 


n 


— 


о 


wm 


р) 


8.2.1 End point security and classification 


The End Point Devices are an essential component 
and enabler for security, it 1s required to establish the 
assurance level of End Point devices, as they manifest 
themselves in different forms with unique requirements 
of the use cases they serve. 


The end point device identity and security assurance 
requirement is shown in Fig. 10. 


8.2.2 Classification of Use Cases 


The use cases may be classified as per clause 7.1.2 of 
TEC-TR-SN-M2M-009 as reproduced below: 


The most important aspect of M2M / IoT Security is in 
how it is able to protect the data generated by the end 
points and the applications that use the end point data 
to create services. The classifications of IoT / M2M Use 
Cases, and the proposed mandatory recommendations, 
are in the context of the said primary objective of M2M 
/ ТоТ data protection 


a) Use Case categories 


1) Mission Critical, High QoS, Sensitive 
Information [CQS] 


2) Mission Critical, High QoS, Non Sensitive 
Information [CON] 
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3) Non Critical, Best Effort, Sensitive 
Information [NBS] 

4) Non Critical, Best Effort, Non Sensitive 
Information [NBN] 

5) Mission Critical, Best Effort, Sensitive 
Information [CBS] 

6) Mission Critical, Best Effort, Non 
Sensitive Information [CBN] 

7) Non Critical, High QoS, Sensitive 
Information [NQS] 

8) Non Critical, High QoS, Non Sensitive 
Information [NON] 


b) Mission Critical, High QoS, Sensitive 


Information [CQS] 


1) All Use Cases serving individual users 
from governmental or non-governmental 
infrastructure that affect health, safety 
or security such as Personal Vehicle 
Automotive Solutions, Metering 
Solutions, Home Automation and Safety 
etc that collect or manage Personally 
Identifiable Information [PII] or Privacy 
Protected Information [PPI] 


c) Mission Critical, High QoS, non-Sensitive 


Information [CON] 


1) All Use Cases serving the public at 
large from Governmental Infrastructure 
such as Emergency Services, Disaster 
Management, Public Safety, Smart 
Cities, Intelligent Transport Systems, 
Automotive Solutions, Financial Services 
(ATMs, PoS, Payment Terminals, Identity 
Terminals), Health Services (ICDS, 
Hospital Management) that do not 


collect or manage information private to 
individuals 


2) АП Use Cases serving the public at large 
from non-governmental infrastructure 
for services such as Emergency Services, 
Disaster Response, Health Services, 
Industrial Safety, Transport Services that 
do not collect or manage information 
private to individuals 


d) Non Critical, Best Effort, Sensitive Information 


[NBS] 


1) All Use Cases serving a private individual 
from governmental or non-governmental 
infrastructure that affect non critical 
information for day to day use but 
collect or manage Personally Identifiable 
Information [PII] or Privacy Protected 
Information [PPI] 


e) Non Critical, Best Effort, non-Sensitive 


Information [NBN] 


1) All Use Cases serving the public at large 
from governmental or non-governmental 
infrastructure that affects non critical 
information for day to day use that does not 
in any way collect or manage information 
private to individuals 


f) Other Classifications 


1) Several other combinations of Criticality, 
Quality of Service and Data Sensitivity 
are possible which can generate further 
classifications 


g) IoT Application shall be classified as per 


classification at (a) above and prominently 
display this classification on Portals and Apps 
for the user to be correctly informed 


8.2.3 Authentication and Authorization framework 


The authentication and authorization of connected 
devices and applications may be as per the ITU-T 
Y.3056. The functional architecture as defined in 9 of 
ITU-T Y.3056 is reproduced in Fig. 11. 


8.2.4 Trust frumework 


The framework for interaction between national trust 
centre, sectoral registrars and international registrars 


Trusted Device 


Client Element 


Bootstrapping 
function 


bootstrag token 


Security 
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Network Operator 
Authentication Element 


Token Management 
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Bootstrapping 
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is shown in Fig. 12. This framework shall allow the 
registration of connected devices and applications, 
vulnerability assessment and management of security 
lifecycle of all IoT/ M2M devices and applications. 


The Information flows may be considered as per ITU-T 
Y.3056, which includes the process of registration 
and transfer, or other such guidelines as published by 
sectoral authorities from time to time. 


Trusted Application 
Application Element 


Token Management 
function 


bootstrap token 


Security 


Key 
Management 
function 


| 
Token Management 
function 


Authorization Element 


Mapping & 
Registration 
function 


Session Control 
function 


Connection Element 
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ANNEX A 


USE CASE BASED REQUIREMENT CATEGORISATION 


The IoT System Reference Architecture addresses the 
IoT Use Cases and Requirements referenced to the 
following standards, gazettes and technical reports 
a) IS 18004-6 Requirements for Internet of 
Things (under development) 
b) TEC 30002 : 2020 oneM2M-Requirements 
c) Gazette Notification No. G.S.R. 1131(E) 
dated 5th September, 2017 of Department 
of | Telecommunications, Ministry of 
Communications, Government of India, and 
d) Use Cases described in TEC-TR-SN- 
M2M-009 — Release 01 Recommendations for 
IoT / M2M Security (Technical report) 


While capturing the requirements across a wide 
variety of divergent domains, that serve as a basis of 
the reference architecture described in this standard, 
the following domains were considered as candidate 
verticals to represent the entire spectrum of vertical 
domains. The detailed requirements for IoT system is 
specified in IS 18004 (Part 6) IoT System Functional 
Requirements (Under development) 


a) Electricity Utility 
b) Water Utility 

c) Water Management 
d) Gas 

e) Smart Street Light 
f) Surveillance 

g) Environment 

h) Traffic Management 
1) Transportation 

j) ICCC 

k) Solid Waste Management 


1) Smart Home 
m) Citizen Engagement Platform 
n) Distribution Automation 
о) Industrial Automation 
p) Smart Health 


In IoT/M2M, a device is an electronic element with 
communication capabilities. This standard attempts 
to classify the devices in the IoT ecosystem in the 
following way: 


Table 2 classifies the devices based on its compute 
capability, the presence of Operating System and the 
methodology used for communication (in purely IP 
or non-IP way). Such categorisation or classification 
of IoT devices is done in order to come up with an 
architectural reference model which along with the 
main functional entities derived from the use cases can 
define the reference architecture that may help towards 
the implementation of IoT solutions. 


Here the categorization or classification of devices do 
not differentiate between sensing and actuating devices 
and general devices. This categorization is purely on 
the basis of the processing capabilities and the way the 
devices communicate. So, those devices which may be 
termed as passive devices for example, ID tags using 
identification technologies such as radio frequency 
identification (RFID) or near field communication 
(NFC), applied to a disposable package, are not 
included as part of devices categorised as IoT devices. 
The rationale behind this is the fact that these passive 
devices would require devices with compute and 
communication capabilities to obtain, process and 
communicate the data to the other entities in the 
ecosystem. 


Table 2 Classification of IoT Devices 


а " Device Type Compute Capacity OS poe asa 
1 High Constrained Devices 8/16 bit Microcontroller NO Non-IP/IP 
2 Constrained Device 16/32 bit Microcontroller NO/RTOS Non-IP/IP 
3 Small Compute Device Single core 32 bit Microprocessors yes IP 
4 Medium Compute Device Single/Dual core 32/64 bit Microprocessors yes IP 
5 Large Compute Device Multi core(>2) 64 bit Microprocessors yes IP 
6 Virtual Machine/Server Multi core VMs/Dockers/Servers yes IP 
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ANNEX B 


BROAD FUNCTIONAL REQUIREMENTS 


The broad functional requirements are being covered 
as a separate standard IS 18004 (Part 6) (under 
development). However, the summary of the same is 
being captured here to give a high level view to the 
readers about the functional requirements fulfilled by 
the IoT System RA. Following list gives the different 
categories in which the functional requirements are 
identified and articulated. 


a) 
b) 
с) 
d) 


Overall System Requirements 
Management Requirements 
Semantics Requirements 
Data Analytics Requirements 
Security Requirements 

f) 


g) 
h) 


Charging Requirements 
Operational Requirements 


Communication Management Requirements 


The Overall System requirements would be covering 
the generic requirements of registration, onboarding, 
communication and data handling etc. by the IoT 
System. 


The management requirement would be providing the 
comprehensive requirements of management of the 
devices within the IoT ecosystem. This would also 
cover the management of the software entities. 


Semantics are extremely important for the 
interoperability within the loT ecosystem and 
also for seamless sharing of data within the IoT 
system. This would be covering Ontology Related 
Requirements,Semantics Annotation Requirements, 
Semantics Query Requirements, Semantics Mashup 
Requirements and Semantics Reasoning Requirements 
etc. 


The ability of the IoT System to support capabilities 
(e.g. processing function) for performing IoT data 
analytics based on semantic descriptions from IoT 
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Applications and /or from the IoT System would be 
covered in the Data Analytics Requirements. It would 
also lay down the requirements from the IoT system 
to support a standardized format for the rules/policies 
used to define service logic. 


The importance of Security for the IoT System is 
paramount. While the overall digital as well as physical 
ecosystem has to follow elaborate security guidelines, 
it is equally important to identify and elaborate the 
security requirements for the IoT System so that the 
fulfilment of the same can be a standardised practice 
for any entity getting onboarded. 


Even though the IoT system does not and shall not 
be prescriptive about the monetisation aspects of 
the IoT deployments, it is important for the sake of 
standardisation to define the Charging Requirements 
so that the IoT System is able to support collection 
of charging specific information related to the 
individual services facilitated by the IoT System (such 
as Data Management, Device Management and/or 
Connectivity Management), Collection of charging 
specific information with concurrent resource usage 
and support mechanisms to facilitate correlation of 
charging information (e.g. of a User) collected for 
IoT Services, IoT Application Services and services 
provided by Underlying Network Operators. 


Following the deployment of the IoT System, it is 
essential to standardize the operational aspects of the 
IoT System. It therefore, becomes necessary to capture 
and define all such essential requirements which are 
mandatory to operationalize any IoT System. 


Last but not the least, the communication management 
requirements are also equally important for any 
IoT System. While the IoT RA is agnostic to any 
communication technology, the generic communication 
management needs shall have to be fulfilled for efficient 
handling and distribution of IoT data. 
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